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I 

FORWARD 

This  document  is  a report  of  the  third  year's  accomplishments  on 
the  Calac  independent  research  task  entitled,  "User  Oriented  Remote  Com- 
puting" (project  number  7701150).  The  authors  are  indebted  to  Thomas  R. 
Jones  for  the  many  constructive  suggestions  he  made,  and  especially  to 
Howard  Weinberger  for  his  constant  interest  and  advice  during  the  course  of 
this  task. 
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ABSTRACT 

\ 

jThe  usefulness  of  computers  in  solving  scientific  problems  is  a 
function  of  the  ease  with  which  users  can  communicate  with  existing  hard- 
ware and  software.  This  research  is  aimed  at  improving  such  man-computer 
communication.  Specifically,  a computer  system  has  been  designed  and 
partially  implemented  which  will  provide  a software  interface  between 
users,  possibly  inexperienced  in  computer  processing  techniques,  and 
available  programs  and  analysis  systems . 

This  system,  denoted  ASSIST  (A  Scientific  Software  Interface 
System  for  Terminal  users),  aids  users  in  accessing  and  utilizing  existing 
applications  software  from  remote  terminals.  The  system  provides  three 
basic  functions.  It  helps  users  find  programs  relevant  to  their  problems; 
it  assists  them  in  preparing  required  input  data;  and  it  aids  in  the 
actual  submittal  of  programs  and  data  for  computer  processing.  In  addi- 
tion, the  system  monitors  usage  of  the  facilities  to  ensure  the  efficient 
and  proper  use  of  available  computer  resources. 

The  basic  approach  has  been  to  design  a language  which  pro- 
grammers can  use  to  describe  program  characteristics  (function,  input 
format,  submittal  requirements,  etc.).  These  descriptions  can  then  be 
interactively  interpreted  by  ASSIST  to  aid  individuals  wishing  to  use  any 
available  program.  Thus,  the  user  has  a helpful  interface  with  which  he 
can  converse  while  he  is  trying  to  find,  prepare  input  for,  or  submit  a 
program. 


In  addition  to  improving  ASSIST,  a major  portion  of  the  current 
research  has  been  directed  at  determining  the  proper  hardware/software/firm- 
ware configuration  to  support  it  and  other  user  oriented  interactive  cap- 
abilities . . 
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INTRODUCTION 

Technological  advances  in  hardware  have  made  computers  practical 
and  economical  tools  for  ever  increasing  numbers  of  users.  More  and  more 
people  with  less  and  less  programming  experience  will  be  using  computers 
in  the  years  to  come.  No  longer  can  systems  be  designed  without  consid- 
eration of  these  ultimate  users.  The  effectiveness  of  future  systems  will 
be  measured  by  the  ease  which  man  can  communicate  with  them. 

Although  a great  quantity  of  problem  solving  software  is  avail- 
able today,  most  is  usable  only  by  those  with  backgrounds  in  computing. 
Non- programming  users  at  Calac  traditionally  depended  upon  professional 
programmers  as  their  interface  with  existing  software.  In  the  computing 
environment  prior  to  1975 } it  was  the  professional  programmer  who  directly 
accessed  both  the  computer  and  the  library  of  existing  programs.  A non- 
programming  user,  with  a problem  to  solve,  would  explain  it  to  some  pro- 
grammer who  would  perform  the  necessary  tasks  to  prepare  a computer 
acceptable  form  of  the  problem  (i.e.,  put  together  program  and  data  with 
required  system  control  information).  The  programmer  would  then  accom- 
plish the  actual  computer  processing  and  return  the  results  to  the  user. 
This  mode  of  operation  had  obvious  inefficiencies  for  many  kinds  of  pro- 
blem solving.  There  were  often  delays  in  processing  and  errors  due  to 
misunderstandings.  With  more  and  more  people  requiring  more  and  more 
computer  processing  there  was  clearly  a need  to  put  them  in  closer  contact 
with  the  computer. 

As  a consequence  of  this  conclusion,  a Direct  Computer  Access 
System,  DCAS,  was  established  which  logically  extended  the  computer  to 
allow  access  to  it  through  remote  terminals.  Initially  DCAS  existed  only 
as  a subset  of  IBM's  Time  Sharing  Option  (TSO).  Although  this  gave  a user 
direct  access  to  the  computer,  it  did  not  improve  his  access  to  the 
library  of  programs.  This  research  has  dealt  primarily  with  the  task  of 
extending  DCAS  to  improve  the  user's  ability  to  directly  utilize  this 
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collection  of  existing  applications  software.  In  effect,  the  poal  has 
been  to  automate  the  interface  function  previously  provided  by  the  pro- 
grammer. In  order  to  accomplish  this  the  programmer  must  be  provided  with 
some  means  for  transferring  his  "knowledge " (or  information  in  his  keeping) 
regarding  the  use  of  specific  analysis  software  to  DCAS.  ASSIST  is  that 
augmentation  of  TSO  which  gives  DCAS  this  capability. 

ASSIST  has  been  designed  to  bring  together  information  regarding 
existing  application  programs  and  potential  users  in  an  interactive  envi- 
ronment (see  Figure  1).  For  each  program  to  be  made  available  through 
ASSIST,  certain  descriptive  information  is  provided  by  a programmer.  This 
information  includes  a general  program  description,  a complete  and  precise 
input  specification,  and  certain  job  control  information  necessary  for 
running  the  program  on  the  computer.  The  user  can  then  interact  with 
various  components  of  ASSIST,  which  have  access  to  this  programmer  sup- 
plied information,  for  solving  some  problem.  If  he  needs  information  re- 
garding the  availability  of  certain  software,  he  can  access  the  Program 
Selection  component.  This  will  tell  him  about  existing  programs  in  a 
particular  category  he  selects.  Once  he  knows  which  program  to  run  he  may 
elect  to  access  the  Input  Preparation  component  to  assist  him  in  preparing 
his  data.  He  may  ask  to  be  prompted  for  every  quantity  needed  or  merely 
to  have  his  data  checked  for  completeness  and,  to  some  degree,  correctness. 
Finally  the  user  can  access  the  Program  Submittal  component  which  will 
automatically  create  all  necessary  job  control  information  and  submit  the 
specified  program  and  data  for  execution. 

During  1975  a preliminary  design  of  ASSIST  was  completed.  The 
component  of  the  system  which  assists  users  in  submitting  programs  was 
developed  and  put  into  controlled  use  for  testing.  This  work  is  described 
in  the  report,  "Engineer  Oriented  Remote  Computing"  (LR  27518).  In  1976 
an  initial  production  version  of  ASSIST,  containing  extensive  users  aids 
for  program  submittal,  was  completed  and  put  into  use.  Other  aids  were 
implemented  and  several  more  were  designed  including  software  to  help 
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users  in  preparing  program  input  data.  A detailed  account  of  the  1976 
progress  on  the  various  components  of  ASSIST  can  be  found  in  the  report, 
"Summary  of  1976  Independent  Research  on  Engineer  Oriented  Remote  computing" 

(LR  28005). 

The  specific  objectives  for  1977  were  two-fold.  The  first  was  to 
improve  the  overall  capabilities  and  performance  characteristics  of  ASSIST, 
and  the  second  was  to  find  a more  suitable  computing  environment  for  hosting 
ASSIST  and  other  interactive  capabilities.  In  particular,  the  feasibility 
of  a distributed  computing  approach  was  evaluated.  This  report  is  divided 
into  two  major  sections,  the  first  being  a description  of  ASSIST  improve- 
ments, and  the  second  an  evaluation  of  various  computing  environments. 
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SECTION  1.0 

ASSIST  IMPROVEMENTS 

The  basic  design  of  ASSIST  was  accomplished  in  1975  and  has  re- 
mained relatively  unchanged  since  that  time.  Implementation  of  the  var- 
ious components  of  the  design  have  proceeded  according  to  greatest  need. 

Of  the  four  major  components  of  the  system, 

o program  selection 
o input  preparation 
o program  submittal 
o usage  monitoring  and  control 

only  program  submittal  has  achieved  full  operational  status.  The  others 
exist  in  various  stages  of  completeness.  This  section  gives  the  present 
status  of  each  component  and  describes  in  detail  the  accomplishments  of 
1977. 

1.1  PROGRAM  SELECTION 

The  purpose  of  this  component  of  ASSIST  is  to  provide  informa- 
tion to  the  user  regarding  available  applications  software.  The  nature 
of  this  information  will  be  such  that  he  may  determine  which,  if  any, 
available  programs  might  be  applicable  to  a given  problem.  Program  titles, 
abstracts,  development  and  revision  dates,  names  of  responsible  pro- 
grammers, and  program  identification  (Reference  File)  numbers  are  examples 
of  the  information  to  be  provided.  Additionally,  this  information  will 
be  made  conveniently  accessible  from  a terminal.  Specifically,  a user 
will  be  able  to  give  a keyword  and  a list  of  program  titles  will  be 
searched  for  the  occurrence  of  the  word  given.  The  program  titles  corre- 
sponding to  matched  keywords  are  returned  to  the  user.  He  may  then  list 
the  abstract  and  other  information  desired  for  selected  programs.  One  of 
the  primary  advantages  of  such  a capability  is  that  it  provides  an  effec- 
tive means  for  disseminating  information  regarding  available  software 
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throughout  a large  community  of  users. 

This  component  was  developed  by  creating  an  on-line  data  set 
with  an  entry  for  each  of  the  PS  I (Program  Setup  Instruction)  macros 
accessible  through  the  program  submittal  component.  In  some  cases  there 
may  be  more  than  one  macro  for  a given  available  program,  but  there  is 
always  at  least  one.  The  entry  for  a given  macro  contains  its  name  (a  one 
to  eight  character  identification),  a title,  the  name  of  the  responsible 
programmer,  and  the  program  reference  file  (RF)  number  of  the  program 
accessed  by  the  macro.  This  RF  number  is  a key  into  an  existing  data  base 
of  progr.am  description  information,  the  iTogram  Reference  Fii^ . This  dat? 
base  is  maintained  by  the  Scientific  Computing  Division  and  contains  tv- 
remainder  of  pertinent  information  for  applications  programs. 

During  1977  the  feasibility  of  linking  the  Program  Reference 
File  directly  to  the  PSI  macro  data  base  was  studied.  This  would  have 
allowed  interactive  users  direct  access  to  Reference  File  information. 

Also  studied  was  the  feasibility  of  extending  the  data  base  searching 
capability  to  include  Boolean  combinations  of  keywords.  Studies  of  user 
needs,  however,  cast  doubts  as  to  the  importance  of  these  capabilities  in 
relation  to  the  computer  resources  that  would  be  required  to  support  them. 
Consequently,  no  improvements  have  been  made  to  the  program  selection  com- 
ponent of  ASSIST,  and  none  is  contemplated  until  a more  definitive  assess- 
ment of  user  needs  can  be  obtained. 

1.2  INPUT  PREPARATION 

The  purpose  of  this  component  of  ASSIST  is  to  aid  the  user  in 
preparing  input  data  for  a program  he  has  chosen  to  run.  It  will  do  three 
things  for  the  user.  It  will  tell  him  what  input  quantities  are  required 
for  a given  program;  it  will  enable  him  to  provide  those  values  in  a con- 
venient manner  (without  requiring  that  he  know  the  specific  data  formats 
required  by  the  program);  and  it  will  check  the  data  he  provides  both  for 
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completeness  and  correctness.  Furthermore,  this  component  can  be  used 
interactively,  prompting  the  user  wuen  necessary  and  allowing  him  to 
correct  errors  as  they  are  discovered.  The  effect  of  this  component  is  to 
put  a user's  guide  to  a program  on-line  and  in  such  a way  that  the  user 
can  converse  with  it. 

The  approach  taken  for  this  component  is  basically  the  same  as 
that  used  for  program  submittal  (See  Section  1.3).  In  particular  a language 
has  been  developed  which  allows  programmers  to  describe  program  input 
requirements.  Actually  this  language  is  just  an  extension  of  the  PS  I 
macro  language  since  the  fundamental  requirements  of  this  component  are 
identical  with  those  of  program  submittal.  Namely,  it  must  interact  with 
a user,  providing  some  information  and  obtaining  other  information,  and 
based  on  that,  construct  a data  set.  In  the  case  of  pj  gram  submittal, 
the  data  set  built  is  job  stream  input  while  in  the  case  of  input  prepara- 
tion, it  is  a data  set  for  input  to  some  program.  These  differences  in  no 
way  affect  the  logical  operation  of  the  component  of  ASSIST  which  inter- 
prets programmer  written  descriptions  and  interacts  with  users . All  that 
is  required,  therefore,  to  be  able  to  provide  assistance  to  the  user  in 
input  generation  is  to  add  certain  constructs  to  the  existing  macro 
language.  In  particular,  constructs  are  needed  which  allow  the  descrip- 
tion of  required  input  parameters , including  types  and  ranges  of  accept- 
able values,  and  the  format  in  which  the  program  expects  them  to  be  given. 

With  such  an  expanded  macro  language,  a programmer  can  describe 
the  input  requirements  for  any  program  in  such  a way  that  data  prepared 
for  that  program  can  be  automatically  checked  for  completeness  and  correct- 
ness, and,  if  desired,  the  input  can  be  prepared  in  an  interactive  mode. 

In  the  latter  case,  information  will  be  requested  of  the  user  through  an 
input  description  (ID)  macro  written  by  a programmer.  Normally,  this 
request  will  be  a list  of  input  parameters  for  which  the  user  must  supply 
values.  Additional  messages  can  be  displayed  to  the  user  at  the  discretion 
of  the  programmer  writing  the  ID  macro.  The  user  can  ask  for  a description 
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of  any  parameter  requested  and  the  values  he  supplies  will  be  checked  for 
proper  type  (e.g.,  character,  integer,  etc.)  and  limits  (e.g.,  0<X<10) 
according  to  information  specified  in  the  ID  macro.  The  user  will  be 
immediately  notified  of  any  errors  and  allowed  to  correct  them.  The  input 
values  will  then  be  formatted  as  required  by  the  program.  When  this  com- 
ponent is  used  just  to  check  a prepared  data  set,  the  data  set  must  be 
properly  formatted.  In  this  case,  a list  of  all  discovered  errors  will  be 
returned  to  the  user.  The  use  of  this  component  coula  result  in  signifi- 
cant savings  of  computer  resources  by  helping  users  to  prepare  program 
input  data  which  are  correct  the  first  time. 

A software  specification  for  the  extended  macro  language  was 
developed  during  1978.  The  design,  coding  and  testing  of  the  required 
software  modules  began  in  1976  and  continued  into  1977*  These  activities 
were  suspended,  however,  when  results  of  the  computing  environments  study 
(see  Section  2)  indicated  that  a major  hardware/software  configuration 
change  might  prove  beneficial.  It  was  decided  to  defer  further  develop- 
ment efforts  on  the  input  preparation  component  until  the  future  computing 
environment  for  ASSIST  was  established. 

1.3  PROGRAM  SUBMITTAL 


The  purpose  of  this  component  of  ASSIST  is  to  simplify  the  task 
of  program  submittal  by  automatically  generating  the  necessary  job  control 
information  required  by  the  operating  system  for  program  execution.  The 
fundamental  concept  is  that  non-programming  users  should  not  be  required 
to  learn  the  details  of  interfacing  with  the  operating  system  in  order  to 
run  jobs  on  the  computer.  The  users  should  be  able  to  communicate  their 
needs  in  terms  meaningful  to  them  not  in  the  language  of  the  operating 
system.  For  example,  a user  desiring  plot  output  should  merely  have  to 
say,  "PLOTS"  or  respond  affirmatively  to  the  question,  "Do  you  want  the 
output  plotted?"  rather  than  have  to  know  how  to  appropriately  modify  the 
DD  (Data  Definition)  statement  of  the  associated  plot  file.  Such  capabil- 
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ities  could  be  of  great  benefit  to  the  experienced  programmer  as  well,  for 
even  with  a knowledge  of  JCL  (job  Control  Language),  it  might  be  far 
simpler  to  allow  ASSIST  to  automatically  generate  necessary  control  in- 
formation. Certainly  there  is  much  less  chance  of  error  for  either  the 
experienced  or  inexperienced  user  when  the  program  setup  and  control  in- 
formation are  produced  automatically. 

The  approach  taken  in  this  research  for  assisting  users  in  pro- 
gram submittal  has  been  to  design  a language,  and  interpreter  for  it, 
which  can  be  used  by  programmers  for  expressing  the  information  necessary 
for  running  programs  on  the  computer.  This  language,  known  as  the  PS  I 
(Program  Setup  Instructions)  Macro  language,  is  an  augmented  job  control 
language  (JCL)  which  allows  construction  of  generalized  sets  of  JCL  for 
the  IBM  operating  system.  The  interpreter  acts  as  a preprocessor  or  macro 
processor,  expanding  programs  written  in  this  language  into  complete  and 
valid  jobs  to  be  executed  on  the  computer. 

In  a typical  case,  a programmer  who  is  familiar  with  a particu- 
lar program  and  the  JCL  required  to  run  it  will  develop  a generalized  set 
of  job  control  instructions  called  a PS  I macro.  This  PS  I macro  will  then 
be  placed  in  an  on-line  library  and,  hence,  will  be  available  to  all  users 
through  the  PS  I macro  processor  known  as  RUNPROG.  Once  a PSI  macro  has 
been  so  created  for  a given  program,  users  can  run  that  program  by  access- 
ing RUNPROG,  without  regard  to  any  JCL  concerns.  Furthermore,  changes 
that  may  be  required  in  the  JCL  due  to  program  modifications,  system  changes, 
or  operational  considerations  can  be  usually  made  in  the  single  version  of 
the  generalized  JCL  in  the  PSI  macro  library  without  requiring  any  change 
on  the  part  of  the  users.  In  cases  where  programming  changes  were  made, 
all  users  will  automatically  get  access  to  the  latest  version  of  the  pro- 
gram. Thus,  this  component  of  ASSIST  can  help  not  only  the  user  in  pro- 
gram submittal,  but  the  programmer  in  program  maintenance  as  well. 

During  the  first  year  (1975)  of  this  research  effort,  the  origi- 
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nal  design  of  the  program  submittal  component  (RUNPROG)  was  developed  and 
a preliminary  version  with  limited  capabilities  was  put  into  production 
use.  In  1976,  the  capabilities  of  this  production  version  were  expanded 
>1  in  accordance  with  the  original  specifications.  The  initial  design  of 

RUNPROG  underwent  a minor  revision  during  1977  and  several  new  features 
were  added  to  the  production  configuration  along  with  capabilities  which 
were  part  of  the  original  design.  A general  description  of  the  modifica- 
tions and  enhancements  made  during  the  third  year  of  this  research  project 
is  given  below.  A complete  description  of  the  current  capabilities  of 
RUNPROG  can  be  found  in  the "Programmer ' s Guide  to  ASSIST". 

1.3.1  Nested  Macro  Calls 

The  capability  to  invoke  one  PS I macro  from  within  another  macro 
was  added  to  the  production  version.  Part  of  the  original  design,  this 
feature  is  particularly  useful  because  it  allows  different  PSI  macros  to 
access  (i.e.,  'CALL')  a common  set  of  augmented  JCL  statements  (i.e.,  a 
PSI  macro),  thereby  eliminating  the  need  for  including  these  statements  in 
each  individual  macro. 

1.3.2  Character  String  Manipulation 

Three  new  functions  not  in  the  original  design  were  added  to 
greatly  enhance  the  character  string  handling  facilities  of  the  macro 
language.  The  capabilities  to: 

1)  concatenate  character  strings  (CONCAT), 

2)  search  a given  string  for  a particular  configuration 
or  substring  (INDEX)  and 

3)  determine  the  current  length  of  a character  string  (LENGTH) 
have  been  implemented  in  the  production  version.  These  new  functions  are 
very  similar  to  their  PL/l  counterparts  and  along  with  the  substring  func- 
tion (SUBSTR)  give  the  user  a full  range  of  character  string  manipulation 
capabilities. 
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1.3.3  Arithmetic  Capabilities 

Due  to  core  limitations,  the  ability  to  evaluate  arbitrary 
expressions  could  not  be  implemented  in  the  production  version.  In  order 
to  compensate  for  this  lack  of  arithmetic  capability,  three  new  functions 
have  been  provided:  ADD,  DUB  and  MULT.  These  functions  allow  the  user  to 
perform  the  arithmetic  operations  of: 

1)  addition, 

2)  subtraction  and 

3)  multiplication, 

respectively  and  are  helpful  in  partially  overcoming  one  of  the  most 
severe  limitations  of  the  macro  language. 

1 . 3 . Programmer 's  Aids 

Several  utility  capabilities  have  also  been  added  to  RUNPROG. 

The  ABEND  statement  produces  a symbol  table  dump  of  all  macro  variables 
and  their  current  values  and  is  helpful  as  a diagnostic  tool  in  debugging 
PS I macros. 

The  DATE  and  TIME  functions  return  the  current  date  and  time  in 
the  following  formats : 

DATE:  MM-DD-YY  where  MM  - month 

DD  - day 

YY  - year 

TIME:  hh:mm:ss  where  hh  - hour 

mm  - minute 

ss  - second 

1.3.5  Response  Improvement 

The  original  implementation  of  RUNPROG  as  an  executable  load 
module  called  from  within  a command  clist  has  been  discarded  in  order  to 
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decrease  the  elapsed  time  spent  within  the  RUNPROG  processor.  Allocation 
and  freeing  of  data  sets  from  TSO  is  a slow  and  costly  process  and  RUNPROG 
> requires  several  data  sets  to  be  allocated  during  execution.  Alternate 

f approaches  which  could  remedy  this  problem  included  allocating  data  sets 

when  a user  first  logs  on  and  doing  this  allocation  from  within  the  pro- 
cessor itself.  Both  of  these  methods  were  studied  and  it  was  decided  that 
a combination  of  these  methods  would  be  used.  This  change  allowed  the  con- 
version of  RUNPROG  from  a command  clist  to  a commend  procedure  and  elimi- 
nated the  time  necessary  to  allocate  data  sets  from  TSO  thereby  greatly 
reducing  elapsed  time  spent  executing  RUNPROG. 

1.3.6  Other  Features  Under  Development 

In  conjunction  with  the  usage  monitoring  and  control  component, 
the  capability  to  monitor  the  use  of  RUNPROG  is  under  development.  This 
function  will  collect  data  regarding  the  use  of  the  program  submittal 
component  (RUNPROG)  and  should  provide  statistical  information  for  evalu- 
ating RUNPROG. 

Several  capabilities  included  in  the  original  design  at  RUNPROG 
are  also  under  development.  These  include: 

1)  expanding  the  number  of  allowable  relational 
operators , 

2)  extending  the  compound  conditional  statement 
and 

3 ) allowing  TSO  data  sets  to  be  copied  into  the 
control  file  being  built. 

At  present,  only  the  ’=’  (equal)  and  ='  (not  equal)  relational 
operators  are  allowed  in  the  evaluation  of  a logical  expression.  This  set 
of  allowable  relational  operators  will  be  expanded  so  that  other  conditions 
may  be  tested  (e.g.,  '>'  (greater  than)  and  '<  1 (less  than). 

The  complete  compound  conditional  statement  has  the  following 

format : 
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IF'  condition  THEN  statement 
EUjE  statement 

The  capability  to  execute  a statement  or  group  of  statements  if  the  tested 
condition  is  false  (i.e.,  an  EISE  clause)  will  be  developed  to  allow  use 
of  the  complete  format  of  the  conditional  statement. 

During  1977,  the  ability  to  copy  a TSO  data  set  into  the  control 
file  being  built  was  studied  and  developed.  However,  during  the  testing 
phase  several  problems  occurred  concerning  the  use  of  system  routines  and 
implementation  was  delayed  until  further  tests  could  be  made.  This  feature 
is  still  in  the  test  phase. 

The  concept  of  being  able  to  execute  the  RUNPROG  processor  in 
the  batch  mode  when  TSO  is  not  active  has  been  studied  and  partially 
developed.  Designed  originally  for  a terminal-oriented,  time-shared 
environment,  this  enhancement  would  allow  the  user  to  access  the  PSI 
macro  library  and  execute  the  RUNPROG  processor  even  when  TSO  is  not 
available. 


Other  enhancements  to  RUNPROG  which  will  be  studied  or  developed 
include  off-loading  inactive  macros  from  the  PSI  macro  library,  consolida- 
tion of  the  current  error  messages  into  a comprehensive  scheme  and  a 
method  of  copying  user-supplied  input  variables  and  their  values  to  the 
control  file  being  built. 
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1.4  USAGE  MONITORING  AND  CONTROL  4 

The  purpose  of  this  component  of  ASSIST  is  to  ensure  the  effi- 
cient usage  of  available  computer  resources  by  developing  adequate  system 
controls  and  through  the  monitoring  of  user  activity.  Since  extensive 
computer  software  and  hardware  resources  have  been  made  available  to  non  - 
programming  users,  there  is  a need  to  prevent  inadvertent  misuse  due  to 
lack  of  computer  experience.  As  a minimum,  sufficient  information  must  be 
collected  in  order  to  determine  whether  the  resources  are  being  efficiently 
utilized.  The  information  so  collected,  since  it  will  reflect  user  activity, 
will  also  be  valuable  for  guiding  efforts  to  improve  the  efficiency  of 
ASSIST  itself. 

The  accomplishments  toward  prevention  of  accidental  misuse  of 
resources  were  designed  and  implemented  within  the  Program  Submittal  and 
Input  Preparation  components  of  ASSIST.  By  their  very  nature  these  com- 
ponents eliminate  many  sources  of  user  errors.  The  Program  Submittal 
component  automatically  determines  many  required  parameters,  and  both 
components  have  capabilities  for  checking  the  correctness  of  user  supplied 
values.  In  the  case  of  program  submittal,  the  computer  resources  requested 
(e.g.  core,  time,  lines  of  output,  etc.)  can  be  controlled,  and,  in  the 
case  of  input  preparation,  the  execution  of  runs  with  erroneous  data  can 
be  prevented. 

1.4.1  Monitoring  RUNPROG  Usage 

Beyond  these  capabilities,  the  primary  method  for  ensuring  the 
efficient  use  of  resources  has  been  through  the  collection  and  analysis  of 
data  relating  to  user  activity.  Much  of  the  relevant  data  is  available  for 
terminal  sessions  just  as  it  is  for  normal  batch  work  through  the  standard 
accounting  procedures.  In  1976,  an  experimental  module  was  designed  and 
developed  to  collect  information  regarding  jobs  processed  by  the  Program 
Submittal  component  (i.e.  RUNPROG).  Because  the  addition  of  this  function 
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would  have  only  aggravated  the  already  poor  response  time,  it  was  decided 
that  implementation  of  the  user  monitoring  function  be  delayed. 

During  the  last  quarter  of  1977,  the  iTogram  Submittal  component 
underwent  a minor  design  revision  which  improved  response  time  signifi- 
cantly (see  Section  1.3.5  )•  This  improvement  allowed  the  User  Monitoring 
component  to  be  implemented.  However,  it  also  required  a change  in  the 
design  of  the  monitoring  of  user  activity. 

In  order  to  prevent  contamination  when  collecting  information 
about  user  activity,  two  new  functions  were  identified  and  incorporated 
into  the  User  Monitoring  module.  One  function  prevents  simultaneous  up- 
date of  the  same  record  by  several  users  and  the  other  prevents  a user 
from  interrupting  the  update  process. 

'//hen  two  or  more  users  are  allowed  access  to  the  same  data  base, 
there  is  always  the  possibility  that  they  will  attempt  to  update  the  same 
record  at  the  same  time,  the  result  being  that  only  one  will  be  successful. 
Recognition  of  this  problem  led  to  the  first  function  which  queues  users, 
allows  only  one  user  at  a time  to  update  the  data  base  and  then  dequeues 
users . 

Initial  implementation  of  the  first  function  demonstrated  the  need 
for  the  second.  If  a user  is  queued  and  attempts  an  attention  interrupt, 
he  abnormally  terminates  from  the  processor  but  does  not  vacate  his  posi- 
tion in  the  queue.  Because  the  user  will  never  perform  the  update  and  be 
removed  from  the  queue  (i.e.  dequeued),  all  users  behind  him  will  remain 
waiting  in  the  queue  until  it  is  forcibly  emptied  (i.e.,  an  IPL  occurs). 

The  second  function  disables  the  attention  interrupt  handler  when  a user 
enters  the  queue  and  enables  it  when  the  user  exits  the  queue  thereby 
avoiding  a possible  bottleneck  in  the  system. 

Testing  of  these  new  functions  is  expected  to  be  completed  in 
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early  1978;  implementation  is  scheduled  for  the  second  quarter. 

1.4.2  Activity  Reporting 

A collection  of  data  is  meaningless  unless  it  is  presented  in 
such  a way  that  useful  information  can  be  derived  from  it,  thus  the  need 
for  reports.  A series  of  MARK  IV  reports  are  being  designed  to  provide 
statistical  information  to  aid  in  the  evaluation  of  the  use  of  ASSIST  and 
to  provide  summary  information  to  aid  management  decisions  regarding 
directions  of  future  growth  for  the  system. 
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SECTION  2 

EVALUATION  OF  COMPUTING  ENVIRONMENTS 

It  has  been  a major  premise  of  this  research  that  greater  pro- 
ductivity among  engineers  and  other  computer  users  can  be  achieved  by 
providing  capabilities  enabling  these  individuals  to  directly  access  the 
existing  computing  hardware  and  software.  It  has  not  been  a purpose  to 
determine  the  validity  of  this  premise  although  it  should  be  pointed  out 
that  ample  supporting  evidence  does  exist.  A study  by  Integrated  Systems 
Support,  Inc.  on  "A  Production  Environment  Evaluation  of  Interactive  Program- 
ming" (l6)  demonstrated  both  an  increase  in  user  productivity  and  a decrease 
in  overall  computing  costs  by  providing  users  with  direct  interactive 
access  to  the  computer  through  remote  terminals.  Furthermore,  question- 
naires distributed  to  users  at  Calac  indicated  a feeling  of  greater  pro- 
ductivity when  direct  computer  access  capabilities  were  available. 

The  extent  to  which  direct  access  capabilities  are  provided, 
the  specific  functions  to  be  performed,  and  the  means  of  doing  it  have 
been  the  subject  of  this  research  task  and  other  related  efforts  over  the 
past  several  years.  The  result  of  these  efforts  has  been  the  development 
of  the  computer  based  system,  DCAS  (Direct  Computer  Access  System).  In 
its  present  implementation  DCAS  exists  in  a centralized  environment. 
Specifically,  the  system  functions  are  imbedded  within  IBM's  TSO  (Time 
Sharing  Option)  portion  of  the  operating  system  OS/MVT  on  a 360/91 
computer. 


Unfortunately,  the  present  system  does  not  adequately  satisfy 
current  needs  and  has  very  little  growth  potential.  It's  capabilities  are 
far  too  limited,  it  is  difficult  to  use,  and  it  is  unresponsive  to  the 
user.  In  addition,  the  present  hardware  is  unreliable  and  the  system 
software  (i.e.  TSO)  is  highly  inefficient.  Even  with  all  these  drawbacks 
users  generally  agree  that  DCAS  is  far  superior  to  past  methods  of  opera- 
tion where  computer  processing  was  done  in  a batch  mode  by  (or  with  the 
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assistance  of)  professional  programmers. 

Since  it  seemed  to  be  only  the  particular  implementation  and  not 
the  basic  system  design  that  limited  the  effectiveness  of  DCAS,  this 
year's  research  was  directed  at  investigating  the  feasibility  of  imple- 
menting DCAS  within  other  hardware/software/f irmware  environments.  In 
particular,  various  forms  of  distributed  computing  environments  were 
studied  and  evaluated.  This  section  is  devoted  to  that  evaluation. 

2.1  EVALUATION  CRITERIA 

Six  areas  were  selected  as  a basis  for  judging  system  effective- 
ness. Specifically,  the  environments  were  evaluated  with  regard  to  how 
well  they  could  support  systems  which  would  provide  the  required  cap- 
abilities, be  easy  to  use,  efficiently  utilize  computer  resources,  be 
reliable,  offer  growth  potential,  and  be  responsive  to  the  users.  These 
criteria  are  more  fully  discussed  in  the  following  sections. 

2.1.1  Capabilities 

It  is  probably  of  primary  importance  that  the  specific  cap- 
abilities of  the  system  be  precisely  established.  This  is  a particularly 
difficult  task  since  needs  are  influenced  by  available  capabilities.  It 
is  usually  difficult  to  express  needs  independently  from  existing  tools. 
When  asked  what  their  needs  are  in  order  to  be  able  to  do  computing  more 
effectively,  users  respond  by  saying  such  things  as, 

"We  need  a bigger  computer."  (or  worse,  "We  need  a CDC  7600.") 

"We  need  remote  terminals."  (or  worse,  "We  need  some  HP  264lA's") 

"We  need  a time  sharing  system."  (or  worse,  "We  need  TSO.") 

When  expressed  in  functional  terms  the  need  for  a larger  computer  becomes 
a need  for  the  means  to  solve  larger  problems  or  for  solving  them  faster. 
Likewise,  the  need  for  remote  terminals  might  become  the  need  to  be  able 
to  conveniently  communicate  with  the  computer  from  remote  locations. 
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Finally,  requesting  a timesharing  system  probably  indicates  the  need  for 
some  interactive  computing  capabilities. 

In  order  to  find  the  best  means  for  providing  direct  access  capa- 
bilities, needs  must  be  expressed  in  a functional,  tool-independent  manner. 

It  must  also  be  understood  that  user  needs  will  continually  grow  (and  even 
change).  Increased  capabilities  create  new  needs  and  obsolete  others.  What- 
ever might  be  determined  to  be  today's  needs  will  probably  be  out-of-date  in 
the  not -to -distant  future. 

With  these  thoughts  in  mind  the  following  capabilities  have  been 
established  as  the  set  required  to  satisfy  user  needs  for  computer  processing 
at  the  present.  These  capabilities  stated  as  functional  requirements,  are 
based  upon  user  provided  information  and  two  years  of  experience  with  the 
present  implementation  of  DCAS . The  functions  can  be  divided  into  nine  areas . 

1)  data  set  creation  and  manipulation 

2)  computer  program  development 

3)  batch  program  submittal 

4)  interactive  program  execution 

5)  command  set  processing 

6)  user  communication 

7)  document  preparation 

8)  system  management 

9)  system  access 

The  functions  can  further  be  divided  into  essential  and  desired 
capabilities.  Those  classified  as  essential  must  be  realizable  in  order  for 
a computing  environment  to  be  acceptable . The  environment  will  then  be 
rated  according  to  how  well  it  is  suited  for  providing  essential  capabilities 
and  how  many  desired  features  it  is  capable  of  supporting.  In  the  following 
sections  the  functional  requirements  are  described.  Essential  functions  are 
noted  with  an  asterisk  (*) . 
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2. 1.1.1  Data  Set  Creation  and  Manipulation 


’ This  is  a fundamental  capability  which  must  be  provided  to  the 

! user.  He  must  be  able  to  create,  identify,  and  store  sets  of  data.  Further- 

more, he  must  be  able  to  retrieve,  modify,  and  display  these  data  sets. 

A data  set  is  defined  here  to  be  any  collection  of  data.  It  could 
be  numeric,  textual  (including  lower  case  letters  and  special  symbols),  or 
an  actual  computer  program.  The  data  sets  themselves  consist  of  lines 
(records)  which  may  be  of  any  size.  The  lines  (records)  of  a data  set  may  be 
all  of  one  size  or  of  varying  sizes.  A given  user  may  create  and  keep 
several  data  sets.  This  collection  will  be  referred  to  as  his  library  of 
data  sets . 


t 


The  specific  data  set  handling  functions  are: 

* A)  create  - form  and  identify  a data  set  by  entering  information 

into  the  system. 

B)  reidentify  - give  a new  name  or  an  alias  to  an  existing  data 
set 

* C)  store  - retain  a data  set  within  the  system  identified  by  its 

name 

* D)  retrieve  - fetch  a data  set  with  a specified  name 

* E)  list  - display  the  contents  of  a data  set  or  a portion  thereof 

* F)  delete  - remove  a data  set  from  the  system 

* G)  copy  - duplicate  a data  set  or  a portion  of  it  optionally 

rearranging  and/or  eliminating  certain  columns  (fields)  of 
lines  (records)  in  the  copy 

H)  describe-as  - associate  a textual  description  with  a data  set 

I)  protect  - prevent  access  to  and/or  modification  of  and/or 
deletion  of  a data  set  except  by  authorized  users 
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j)  modify  - change  contents  of  a data  set  as  follows: 

* l)  insert  - add  one  or  more  lines  (records)  to  a data  set 

at  some  location 

2)  replace  - substitute  one  or  more  lines  (records)  with 
another  line  (record)  or  set  of  lines  (records) 

* 3)  delete  - remove  one  or  more  lines  (records)  from  a data 

set 

4)  move  - transfer  one  or  more  lines  (records)  from  one 
place  to  another  within  a data  set 
*5)  copy  - duplicate  one  or  more  lines  (records)  one  or  more 
times  from  the  current  or  other  data  set  into  the  current 
data  set  at  some  location 

6)  search-for  - find  the  first  occurrence,  first  n occur- 
rences, or  all  occurrences  of  a string  within  a range  of 
lines  of  a data  set,  optionally  limiting  the  search  to 
certain  columns  (fields)  within  the  lines  (records) 

7)  change  - alter  one  or  more  lines  (records)  of  a data  set 
as  follows : 

a)  insert  - place  one  or  more  additional  characters  at 
some  point  within  a line  (record) 

b)  delete  - remove  one  or  more  existing  characters  from 
a line  (record) 

* c)  alter  - replace  one  string  with  another  string  in 
one  or  more  lines  (records)  optionally  limiting 
replacements  to  certain  columns  (fields)  within  the 
lines  (records) 

K)  undo  - restore  data  set  to  the  form  it  had  just  prior  to 
execution  of  the  last  command  or  last  n commands 
* L)  list-catalogue  - display  the  names,  and  optionally  descrip- 
tions, of  all  data  sets  in  a user's  library 
M)  compare  - test  two  data  sets,  or  portions  thereof,  to  see  if 
they  are  identical  and  list  any  differences,  optionally  spe- 
cifying the  columns  (fields)  in  the  lines  (records)  to  be  com- 
pared 
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N)  shift  - move  one  or  more  lines  (records),  or  portions  thereof 
a specified  number  of  columns  (positions)  right  or  left 

O)  sort  - rearrange  lines  (records)  or  a data  set  into  either 
ascending  or  descending  order  based  upon  a selected  range  of 
columns  (field)  in  the  lines  (records) 

P)  check  - test  a data  set  for  compliance  with  some  established 
format 

2. 1.1. 2 Program  Development 

Users  must  be  able  to  interactively  create  and  check  out  computer 
programs.  As  a minimum,  these  capabilities  must  be  available  lor  Lhe  r'uhi'KAh 
programming  language.  It  is  also  highly  desirable  that  these  capabilities 
be  available  for  PL/l,  Assembler  Language,  and  APL.  The  specific  functions 
needed  are  as  follows : 

A)  scan  - syntactically  check  a statement  or  set  of  statements 
for  compliance  with  the  rules  of  the  particular  language 

B)  compile  - generate  object  code  from  a given  source  statement 
program  displaying  any  compilation  errors  to  the  user 

C)  assemble  - cause  an  Assembler  Language  program  to  be  assembled 
(i.e.,  generate  object  code) 

D)  link  - generate  a load  module  from  a given  object  module 

E)  debug  - test  a program  for  proper  execution  and  locate  program- 
ming errors  as  follows : 

1)  execute  - cause  execution  of  the  program  to  begin  at  a 
specified  statement  and  optionally  specify  where  execu- 
tion is  to  stop 

2)  interrupt  - cause  execution  to  cease  immediately 

3)  list-vari ables  - display  the  current  value (s)  of  program 
variable (s) 

4)  change -value  - modify  the  value  of  a variable  or  set  of 
variables 

5)  list  - display  a statement  or  set  of  statements 
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6)  modify  - change  (including  all  subfunctions  described  as 
part  of  the  "modify"  function  under  "Data  Set  Creation 
and  Manipulation")  the  contents  of  the  program 

7)  set-stop  - designate  a statement  in  the  program  where 
execution  will  stop  whenever  the  statement  is  reached 

8)  remove-stop  - remove  the  designation  that  execution  should 
stop  at  some  statement 

9)  trace-variables  - display  the  value  of  a specified  varia- 
ble whenever  the  value  changes 

10)  trace-flow  - display  indication  of  each  transfer  of 
control  during  program  execution 

2. 1.1. 3 Batch  Processing 

Capabilities  must  be  provided  to  allow  users  to  perform  batch  pro- 
cessing of  computer  programs.  The  specific  functions  needed  are  as  follows: 

* A)  submit  - cause  a program  to  be  submitted  for  batch  execution 

* B)  list-output  - display  the  output  of  a job  run  in  batch  mode 

* C)  determine -status  - return  the  current  status  of  a job  submitted 

for  batch  execution 

* D)  cancel  - cause  a job  submitted  for  batch  execution  to  be  can- 

celled 

E ) scan  - syntactically  check  job  control  statements 

* F)  save-output  - put  output  from  a job  into  a data  set 

G)  access -data-set  - provide  access  to  a data  set  from  a job 
executing  in  a batch  mode 

H)  plot  - display  plot  output 
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2. 1.1. 4 Interactive  Program  Execution 


Users  need  to  be  able  to  create  and  run  interactive  programs.  The 
specific  functions  needed  are  as  follows: 

* A)  run  - call  up  and  execute  a program  interactively 

b)  suspend  - cause  an  interactive  program  to  temporarily  halt 
execution 

C)  resume  - cause  a suspended  interactive  program  to  resume 
execution 

* D)  cancel  - terminate  execution  of  an  interactive  program 

E)  access -data-set  - provide  access  to  r data  set  fear  a nvcgrn ■ 

executing  interactively 

F)  calculate  - determine  and  display  the  result  of  a specified 
numerical  calculation 

G)  plot  - generate  and  display  a plot  from  data  given 

2. 1.1. 5 Command  Set  Processing 

A capability  to  execute  sets  of  interactive  commands  as  a group 
must  be  provided.  Ideally,  the  command  language  will  be  sufficiently  rich 
to  allow  a full  programming  capability  at  this  level.  That  is,  logical 
testing,  branching,  looping,  and  input/output  constructs  should  be  part  of 
the  command  language.  Specific  functions  needed  are  the  following: 

* A)  execute  - execute  a set  of  interactive  commands 

B)  suspend  - cause  the  execution  of  a command  set  to  be  tempor- 
arily halted 

C)  resume  - cause  the  execution  of  a suspended  command  set  to 
resume 

D)  scan  - syntactically  check  statements  of  the  command  language 
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2. 1.1. 6 User  Communication 

It  must  be  possible  for  those  maintaining  the  system  to  communicate 
with  users  and  for  users  to  communicate  with  each  other  and  the  system  oper- 
ator. The  following  specific  functions  are  required: 

* A)  send  - send  a message  to  a user,  a set  of  users  or  the  system 

operator 

* B)  hold-messages  - cause  messages  (except  those  sent  by  the  oper- 

ator) to  be  held  in  the  user's  message  file  rather  than  be 
displayed  immediately 

* C)  list-messages  - display  and  delete  all  messages  in  the  user's 

message  file 

D)  associate-message  - cause  a message  to  be  associated  with  a 
data  set  such  that  any  time  the  data  set  is  accessed  the 
message  is  sent  to  the  user  accessing  it 

2. 1.1. 7 Document  Preparation 

Capabilities  are  needed  to  enable  users  to  create,  modify,  and 
maintain  textual  documents  through  the  system.  All  functions  described  in 
section  2. 1.1.1  on  "Data  Set  Creation  and  Manipulation"  must  be  available 
for  document  data  sets,  and  in  addition  the  following  functions  are  required: 

A)  format  - specify  which  lines  are  to  be  formatted  before  dis- 
playing and  which  are  to  be  displayed  as  they  are  by  use  of 
the  following  functions: 

1)  set -line -width  - cause  lines  making  up  paragraphs  (to  be 
formatted)  to  be  adjusted  so  that  each  line  will  contain 
as  many  words  of  the  text  as  possible  without  exceeding 
the  line  width  specified 

2)  start -paragraph  - cause  a new  paragraph  to  begin  at  a 
specified  point 

3)  center -line  - cause  line  to  be  centered  on  page 

4)  indent  - specify  manner  of  indention  for  a paragraph 
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5)  suppress-window-lines  - prevent  the  f'ril  1ine  of  : .>-■ 

graph  from  being  the  last  line  on  a page  or  the  last  line 
of  a paragraph  from  being  the  first  line  on  a page 

B)  set -page -depth  - cause  all  pages  to  have  the  size  specified 

C)  title  - cause  a title  to  be  put  on  every  page 

D)  number-pages  - cause  all  but  the  first  page  to  be  sequentially 
numbered 

E)  set-spacing  - specify  number  of  blank  lines  to  be  inserted 
between  lines  of  text 

2. 1.1. 8 System  tianagement 

Capabilities  must  be  provided  to  control  access  to  and  use  of  the 
system  including  the  reporting  of  resource  usage  information.  It  must  be 
possible  to  specify  for  each  user  an  identification  which  will  be  the  name 
by  which  the  system  knows  the  user.  Also,  the  capability  to  establish  a 
password  for  a user  which  will  restrict  unauthorized  access,  and  to  specify, 
for  each  user,  a set  of  valid  account  numbers  for  the  purpose  of  charging 
the  computing  resources  expended.  Additionally,  a capability  to  define  for 
each  user  his  limits  of  access  and  use  of  resources  is  required  (i.e.,  the 
functions  and  the  types  and  amounts  of  resources  he  is  allowed  to  use). 
Finally,  it  must  be  possible  to  keep  any  other  information  about  users  as 
required  (e.g.,  this  may  include  his  organization  identification,  address, 
phone  number  and  the  like).  The  specific  functions  required  to  maintain  all 
this  user  information  and  monitor  resource  utilization  are  as  follows: 

* A)  add-user  - enter  a new  user  and  his  information  set  to  the 

system 

* B)  change -information  - modify  the  user  information 

* C)  delete-user  - remove  a user  from  the  set  of  authorized  users 

* D)  list-users  - generate  a list  of  all  users  or  a subset  thereof, 

optionally  listing  any  of  the  user  associated  information 

* E)  cancel-user  - terminate  the  session  of  an  active  user 
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* F)  charge  - determine  and  optionally  display  the  computer 

resources  expended  by  a user  for  the  current  session  or  over 
some  period  of  time 

* G)  report -resource -usage  - generate  a report  containing  all 

computer  resource  usage  by  all  or  a subset  of  all  users  over 
some  period  of  time 

H)  report -function -us age  - generate  a report  containing  statis- 
tics on  usage  of  all  system  functions  over  some  period  of 
time  (including  response) 

* l)  send -broadcast-message  - enter  a message  into  a broadcast 

data  set  which  is  displayed  to  all  users  each  time  they  log 
on  to  the  system 

* J)  delete-broadcast-message  - remove  a message  from  the  broad- 

cast data  set 

K)  monitor-user-activity  - cause  all  terminal  input  and  output 
of  a user  to  be  displayed  or  printed  elsewhere 

2. 1.1. 9 System  Access 

The  means  to  identify  oneself  to  the  system  in  order  to  gain  access 
to  its  capabilities  and  to  specify  to  which  account  the  expenditure  of  re- 
sources is  to  be  charged  must  be  provided.  The  following  functions  are  re- 
quired : 

* A)  logon  - gain  access  to  the  system  by  specifying  user  identi- 

fication, possibly  a password,  and  the  account  number  to  which 
computing  resource  expenditures  are  to  be  charged 
B)  change -account  - specify  that  all  subsequent  work  is  to  be 
charged  to  the  new  account  number  specified 

* C)  logoff  - exit  from  the  system 
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2,1.2  Ease  of  Use 

A system  can  provide  all  essential  capabilities  and  still  be 
difficult  to  use.  An  important  feature  of  any  system,  therefore,  is  its 
ease  of  use.  Ease  of  use  encompasses  many  varied  concepts  including  the 
following : 

A)  Learning-  Can  the  system  be  easily  learned?  Can  an  individual 
learn  how  to  use  it  on  his  own  or  is  formal  training  required? 
How  long  does  it  take  to  become  proficient? 

B)  Prompting  - Is  the  user  prompted  when  he  fails  to  supply  re- 
quired information? 

C)  Tutoring  - Can  the  user  obtain  help  from  the  system  when  he 
doesn't  know  how  to  do  something? 

D)  Use  of  Abbreviations  - Can  the  user  abbreviate  commands? 

Can  he  abbreviate  other  information  such  as  his  data  set 
names? 

E)  Editing  Data  Sets  - Are  there  features  to  facilitate  the 
modification  of  data  sets? 

1)  Can  lines  of  a data  set  be  referred  to  by  line  numbers 
(whether  or  not  the  numbers  are  part  of  the  data  set 
itself) ? 

2)  Can  a line  or  set  of  lines  be  modified  merely  by  dis- 
playing them,  making  physical  changes  in  them  (including 
overtyping,  inserting,  or  replacing  characters),  and  re- 
entering them  to  the  system? 

3)  Can  a block  of  lines  be  entered  a once? 

4)  Are  the  results  of  changes  automatically  displayed  to 
the  user? 

5)  Can  lines  of  any  length  be  handled? 

6)  Can  logical  tabulation  points  be  established? 

7)  Are  various  character  sets  available? 
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F)  Entering  Commands  - Can  a previously  entered  command  be  re- 
entered, possibly  modifying  it,  without  completely  retyping 
it? 

G)  Use  of  Physical  Devices  - Are  the  devices  available  easy  to 
use? 

H)  Viewing  Computer  Output  - Can  the  user  move  about  within  his 
output ? 

I)  Entering  Data  - Can  data  be  remotely  entered  without  typing 
(e.g. , from  tape)? 

J)  Locally  Storing  Data  - Can  data  be  stored  at  the  users  local 
site  (remote  from  the  central  facility)  in  other  than  printed 
form  (e.g.,  on  tape)? 

K)  Transferring  Data  - Can  data  be  easily  transferred  to  a site 
outside  of  the  environment  of  the  system? 

L)  Displaying  Information  - Can  the  cursor  on  a terminal  be 
controlled  from  an  interactive  program?  Are  various  character 
sets  available  on  the  terminals?  Do  terminals  have  blinking, 
half  bright,  inverse  video,  upside  down,  90  degree,  etc. 
display  features? 

M)  Sending  Messages  - Can  messages  be  sent  even  when  the  rest  of 
the  system  is  inoperative? 

N)  Submitting  to  batch  - Can  batch  submittals  be  made  without 
knowing  the  job  control  language  of  the  host  computer? 

2.1.3  Efficiency 

An  important  consideration  of  any  system  is  its  cost  in  terms  of 
computer  resources  utilized.  The  computing  environment  must  make  possible 
the  efficient  implementation  of  the  required  system  functions.  In  particu- 
lar, the  most  used  functions  must  be  capable  of  the  highest  degree  of  effi- 
ciency in  their  implementation. 


LOCKHEED 


2-13 


LR  2rl4t 


2.1.4  Availability 

Availability  refers  to  the  degree  to  which  a user  has  access  to 
the  computing  capabilities  he  needs.  This  encompasses  two  attributes  of  the 
computing  environment.  The  first  is  its  capacity.  There  must  be  sufficient, 
computing  power  and  numbers  of  terminals  and  other  peripheral  hardware  to 
serve  the  needs  of  the  users  during  times  of  peak,  system  activity.  The  second 
attribute  is  system  reliability.  The  system  must  be  kept  running  at  or  above 
the  9%  level  during  prime  shift  hours,  Furthermore , the  computing  environ- 
ment should  be  such  that  it  contributes  toward  implementation  of  a system 
which  can  continue  to  operate  at  some  level  even  when  portions  of  the  hard- 
ware and/or  software  are  not  functioning. 

2.1.5  Expandability 

Another  important  attribute  of  any  computing  environment  is  its 
flexibility  in  terms  of  size  and  capabilities.  Can  the  system  be  easily 
expanded  to  handle  more  users?  Can  its  size  be  diminished  if  the  work  load 
decreases?  Can  new  capabilities  be  easily  incorporated  into  the  system? 

The  system  must  be  capable  of  growing  or  shrinking  in  a cost  effective 
manner  as  changes  in  the  work  load  and  needs  of  the  users  occur. 

2.1.6  Responsiveness 

Finally  the  speed  with  which  the  system  can  act  upon  user  requests 
must  be  considered.  This  is  possibly  one  of  the  most  critical  factors 
contributing  toward  user  satisfaction.  Naturally,  the  time  it  takes  to  com- 
plete a task  depends  upon  its  complexity,  but  the  computing  environment  must 
be  such  that  users  are  not  frustrated  by  unreasonable  delays  in  servicing 
requests.  As  a minimum,  the  system  must  be  capable  of  responding  to  trivial 
or  fundamental  requests  within  one  second  90%  of  the  time  and  within  two 
seconds  99%  of  the  time. 
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2.2  EVALUATION  OF  COM] WING  ENVIRONMENTS 


Four  basic  types  of  computing  environments  will  be  discussed  and 
evaluated  in  this  section.  There  are,  naturally,  many  other  ways  of 
classifying  environments,  and  all  combinations  of  those  to  be  described  are 
possible.  A complete  description  of  computer  interconnection  structures 
has  been  attempted  by  Anderson  and  Jensen  (l). 

A computing  environment  can  be  centralized  or  decentralized.  If  it 
is  decentralized  it  can  be  hierarchically  organized  or  not.  If  it  is  non  - 
hierachical,  it  can  be  connected  or  unconnected.  Thus,  the  four  classes  of 
environments  which  will  be  evaluated  are: 

A)  centralized 

B)  hierarchically  decentralized 

C)  non  hierarchically  connected 

D)  unconnected 

2.2.1  Centralized  Environments 


A centralized  environment  is  one  in  which  a single  computer  (agent) 
performs  all  system  functions.  This  is  essentially  the  present  DCAS  environ- 
ment where  a number  of  terminals  are  connected  to  a central  computer  (an  IBM 
360/91)  and  operate  in  a time  sharing  mode  (TSO).  'The  centralized  environment 
is  depicted  in  Figure  2. 

Because  of  the  power  of  the  central  computer,  this  environment  has 
the  potential  to  provide  almost  every  desired  capability.  In  fact,  time 
sharing  systems  exist  for  most  large  machines  which  already  provide  most  of 
the  desired  capabilities  as  specified  in  section  2.1.1.  Thus,  very  little 
new  software  development  would  be  required  in  such  an  environment.  Although 
there  is  no  inherent  reason  that  systems  implemented  in  a centralized  environ- 
ment should  be  difficult  to  use,  experience  with  one  such  system,  TSO,  has 
shown  that  ease  of  use  is  not  necessarily  guaranteed  in  such  an  environment. 
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Figure  2 . Centralized  Environment 
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The  more  capabilities  a system  has  the  more  likely  it  is  to  be  difficult 
to  use.  Hence,  there  may  be  tradeoffs  between  "capabilities"  and  "ease  of 
use"  in  the  evaluation  of  a computing  environment.  In  a centralized  environ- 
ment, however,  it  is  clear  that  these  two  criteria  can  be  satisfactorily  met. 

The  next  evaluation  criterion  is  efficiency.  Centralized  environ- 
ments which  service  many  simultaneous  users  operate,  by  necessity,  in  time 
sharing  mode,  and  time  sharing  is  inherently  inefficient.  In  particular, 
there  is  a significant  overhead  associated  with  swapping  users  in  and  out 
of  main  memory  and  in  keeping  track  of  all  active  users.  A significant 
utilization  of  computer  resources  is  also  required  to  control  the  time  shar- 
ing activity  itself.  Although  computers  exist  which  have  been  designed  to 
operate  efficiently  in  a time  sharing  environment,  such  is  not  the  case  with 
large  scale  computers  of  the  IBM  360/370  variety. 

As  far  as  availability  is  concerned  the  centralized  environment 
suffers  from  the  problem  that  when  the  host  machine  is  not  operating,  the 
entire  system  is  unavailable  for  use.  Thus,  system  availability  is  dependent 
upon  the  reliability  of  the  central  host.  Experience  with  the  IBM  360/91 
has  shown  this  to  be  a serious  problem. 

The  expandability  or  growth  potential  in  a centralized  environment 
is  likewise  limited  by  the  host  machine.  Once  the  capacity  of  the  machine 
is  reached  the  system  cannot  grow  easily.  Also,  should  a decrease  in 
interactive  usage  occur,  the  unused  capacity  of  the  central  machine  might  be 
wasted . 


The  final  criterion  is  responsiveness.  Responsiveness  in  a centra- 
lized environment  is  primarily  a function  of  the  efficiency  of  the  central 
host.  Experience  with  TSO  on  the  IBM  360/91  has  shown  that  acceptable  re- 
sponse is  attainable  only  through  allocation  of  considerable  amounts  of 
machine  resources. 
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The  centralized  environment  can  be  considered  a reasonable 
approach  only  if  efficient,  and  thereby  responsive,  hardware  and  software 
can  be  acquired  for  interactive  use.  Even  then  the  questions  of  system 
availability  (reliability)  and  expandability  (growth  potential)  must  be 
carefully  considered. 

2.2.2  Hierarchically  Decentralized  Environments 

Decentralization  can  imply  many  different  concepts.  It  can  suggest 
that  the  computing  hardware  is  geographically  distributed,  that  data  is  ai  - 
tributed  among  various  computers,  or  that  the  computing  functions  are  dis  c 
buted  among  various  pieces  of  hardware,  in  this  discussion  an  environment 
will  be  considered  to  be  decentralized  if  the  last  of  these  is  true  even 
when  hardware  is  not  geographically  distributed  and  when  all  data  is  centrally 
controlled.  Borrowing  from  C.  V.  Ravi  (l4),  an  environment  is  said  to  be 
decentralized  whenever  computing  functions  (tasks)  are  distributed  among 
different  computing  agents  (hardware,  software,  and  firmware  components). 
Stretching  this  point  even  the  so  called  centralized  environment  previously 
discussed  is  actually  decentralized  because  certain  trivial  computing 
functions  (such  as  data  entry  and  simple  editing)  are  performed  by  the  ter- 
minals. Certainly  in  the  case  of  intelligent  terminals  one  would  have  to 
call  the  environment  decentralized.  Kor  the  current  discussion  an  environ- 
ment will  be  considered  to  be  decentralized  only  if  significant  computing 
functions  are  performed  by  agents  other  than  the  central  host  processor. 

A decentralized  environment  is  hierarchically  organized  if  the 
* computing  agents  are  divided  into  levels,  if  each  agent  is  connected  by  a 

communications  link  to  an  agent  of  the  next  higher  level,  and  if  there  is 
single  agent  at  the  top  level.  In  other  words,  the  environment  is  a tree 
structure  with  the  branches  being  lines  of  communication  and  where  agents  at 
one  level  control  sets  of  agents  at  the  next  lower  level.  For  the  purpose 
of  this  discussion,  an  environment  will  be  considered  to  be  hierarachical 
only  if  no  other  lines  of  communication  exist.  In  particular,  communication 
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lines  between  agents  two  or  more  levels  apart  or  between  agents  at  the  same 
level  are  not  permitted.  A simple  and  typical  hierarchically  distributed 
environment  is  depicted  in  Figure  3* 

Environments  of  this  type  are  capable  of  supporting  the  fiill  range 
of  required  capabilities  since  access  to  the  central  host,  even  if  indirect, 
is  always  possible.  Hierarchically  distributed  environments  can  promote  ease 
of  use  for  certain  sets  of  users.  They  may  be  able  to  use  simpler,  limited 
systems  residing  on  intermediate  computers  rather  than  relying  on  a complex, 
all  encompassing  system  residing  on  the  mainframe  host.  In  fact,  in  such  an 
environment  there  is  the  possibility  of  developing  or  acquiring  highly 
specialized,  easy  to  use  systems  for  particular  classes  of  users. 

Efficiency  can  be  much  better  in  a distributed  environment  than  in 
the  centralized  case  because  much  of  the  processing  can  be  accomplished  by 
less  costly  hardware  located  (at  least  logically  if  not  physically)  closer 
to  the  user.  Certain  editing  functions,  for  example,  might  be  accomplished 
directly  by  a terminal,  compilation  of  source  code  might  be  done  on  a mini- 
computer, and  small  calculations  might  be  handled  by  a micro -processor  with- 
in a terminal.  The  off-loading  of  these,  and  possibly  other  such  functions, 
would  greatly  reduce  the  amount  and  frequency  of  data  transfer  between  the 
user  and  the  central  computer.  This  would  also  reduce  the  time  sharing  over- 
head burden  and  thereby  improve  the  overall  system  efficiency  or  cost  effect- 
iveness . 


Availability  of  the  system  in  a distributed  environment  is  signi- 
ficantly improved  over  the  centralized  case.  It  is  no  longer  true  that  all 
users  are  dependent  upon  a single  piece  of  computing  hardware,  if  signifi- 
cant processing  capability  has  been  off-loaded,  then  at  least  that  processing 
can  continue  regardless  of  the  state  of  the  central  computer.  System  avail- 
ability is  a function  of  the  extent  to  which  processing  capabilities  have  been 
distributed  and  the  redundancy  built  into  the  hardware  configuration.  In  a 
distributed  environment  it  might  be  reasonable  to  have  an  extra  mini-computer 
in  case  one  malfunctions  while  having  and  extra  large  mainframe  is  usually 
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Figure  3-  Hierarchically  Decentralized.  Environment 
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impractical. 

The  distributed  environment  is  also  easily  expandable  (or  contract- 
able)  since  mini-or  micro-computers  could  be  added  (or  subtracted)  as  work 
load  conditions  changed. 

Finally,  with  regard  to  responsiveness,  the  distributed  environment 
has  great  advantage  over  the  centralized  case.  For  computing  functions  which 
have  been  assumed  by  intelligent  terminals  (terminals  with  micro-processors), 
the  user  no  longer  operates  in  a time  sharing  mode.  Hence,  his  response  is 
usually  instantaneous.  In  other  cases  computing  functions  may  be  performed  by 
mini -computers  which  have  been  designed  for  interactive  time  sharing  and  are 
hence  more  responsive.  However,  there  will  undoubtedly  be  some  functions 
which  will  take  longer  to  accomplish.  For  example,  any  function  requiring 
the  transfer  of  information  between  the  terminal  and  the  mainframe  host,  or 
between  agents  non  hierarchically  connected,  will  be  less  responsive.  This 

fact  opens  the  question  of  where  data  should  be  stored  in  such  an  environment . 

Obviously  they  should  be  stored  as  close  as  possible  to  the  computing  agent 
which  needs  access  to  them.  If  a set  of  data  is  needed  at  more  than  one 
level  in  the  hierarchy,  it  should  probably  be  stored  at  the  highest  level  it 
is  needed.  While  this  policy  will  facilitate  central  control  of  data,  it 
might  also  require  great  amounts  of  data  transfer.  This  could  have  adverse 
effects  on  both  efficiency  and  responsiveness. 

Clearly,  a hierarchically  decentralized  environment  can  support  a 
complete  interactive  computing  system.  Determining  the  proper  configuration 
for  particular  needs,  however,  is  not  likely  to  be  an  easy  matter.  The  suita- 
bility of  such  an  environment  and  the  proper  distribution  of  functions  among 

agents  will  be  largely  determined  by  data  transfer  requirements. 
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2.2.3  Non-Hi erarchically  Connected  Environments 

This  clasB  of  environments  includes  all  those  which  are  fully 
connected  but  not  hierarchically  organized.  Each  computing  agent  is  linked 
by  a communications  line  to  another  agent  but  there  are  no  discernable  levels 
in  such  an  environment.  A ring  structure  like  that  depicted  in  Figure  4 is 
a good  example  of  a non-hierarchically  connected  environment.  The  capabili- 
ties supportable,  ease  of  use,  availability,  and  expandability  characteris- 
tics are  essentially  the  same  as  for  hierarchically  connected  environments. 
Efficiency  and  responsiveness  on  the  other  hand  are  dependent  upon  the 
specific  functions  considered.  Typically,  such  an  environment  gives  a >;-<i 
good  response  for  some  functions,  namely  those  directly  available  on  the  age.-u. 
to  which  he  is  connected.  The  system  responsiveness  to  other  functions  de- 
pends upon  the  number  of  communication  paths  which  must  be  travelled  and  the 
amount  of  information  which  must  be  transmitted.  Responsiveness  can  be  im- 
proved by  adding  communications  lines,  but  this  will  tend  to  decrease  overall 
system  efficiency.  Maintaining  central  control  of  data,  or  central  control 
of  anything  for  that  matter,  in  such  an  environment  is  difficult  since  there 
is  no  top  level  computing  agent.  This  would  appear  to  be  a serious  problem 
in  cases  where  many  users  are  involved  in  a single  project.  If  solvable  at 
all,  it  is  likely  to  adversely  affect  system  efficiency. 

2.3.4  Unconnected  Environments 


This  last  classification  of  environments  is  one  in  which  no  lines 
of  communication  exist  between  computing  agents.  Figure  5 depicts  this  case. 
There  is  nothing  inherent  in  such  an  environment  to  limit  ease  of  use,  and 
efficiency,  responsiveness,  and  overall  availability  are  at  maximum  levels. 
Since  there  are  no  connections  between  agents,  system  overhead  is  minimized 
and  failure  of  one  agent  in  no  way  affects  the  others.  Likewise,  the  system 
can  be  easily  expanded  since  adding  a new  agent  can  be  done  without  consider- 
ation of  the  rest  of  the  environment.  The  problem  with  this  environment,  of 
course,  is  that  users  are  greatly  limited  in  the  capabilities  available  to 
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them.  In  particular,  they  can  use  only  those  ltuictions  available  on  the 
computing  agents  to  which  they  have  access.  Moreover,  managing  data  or 
users  at  a global  level  is  not  possible,  and  communication  among  users  is 
not  supportable . 
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I 

CONCLUSIONS  AND  RECOMMENDATIONS 

I 

The  results  of  the  computing  environments  study  are  summarized  in 
the  table  shown  in  Figure  6.  Only  the  fully  connected  decentralized  environ- 
ments score  at  acceptable  levels  for  all  evaluation  criteria,  with  the  ; 

hierarchical  organization  having  a slight  edge.  Decentralization  appears  to 
offer  significant  potential  for  both  improving  service  to  interactive  users 
and  reducing  computing  costs.  Based  on  this  conclusion  the  following  re- 

1 

commendations  are  made . \ 
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1)  Establish  a precise  and  complete  specification  of  user  re- 
quirements for  interactive  computing.  Although  such  a specification  was 
produced  as  part  of  this  research  task,  it  should  be  reviewed  by  end  user 
organizations  and  modified  as  necessary  to  ensure  that  it  truly  reflects 
user  needs.  Furthermore , user  requirements  need  to  be  ordered  in  terms  of 
relative  importance  so  tradeoffs  can  be  properly  evaluated. 

2)  Determine  the  best  configuration  of  computing  hardware  and 
software  to  satisfy  the  established  user  needs.  This  must  be  a joint  effort 
involving  Scientific  Computing,  Computer  Systems,  and  all  end  user  organiza- 
tions . 

3)  Develop  a plan  for  acquisition  of  any  hardware  and  software 
necessary  to  build  a prototype  of  the  configuration  selected. 

4)  Prepare  a plan  for  evaluating  the  effectiveness  of  the  prototype 
configuration  for  satisfying  users'  needs  for  interactive  computing. 
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